If config changes added to the import-2.1.x branch are pushed to the bugfix-2.1.x branch before a PR is merged, why have both branches? We can just drop the whole import-2.1.x branch thing & simplify the process for everyone.

If config changes added to the import-2.1.x branch are pushed to the bugfix-2.1.x branch before a PR is merged….

Although it takes an extra minute to build bugfix-2.1.x the process is transparent, it exercises the config building script, and it produces a branch with only 3 commits that is faster to git fetch for CI. At this point, renaming import-2.1.x to bugfix-2.1.x and modifying the workflow so that contributors must edit bugfix-2.1.x directly would be a bit of a hassle without any major benefits, so for now we'll just carry on. At some later date we can revisit this workflow.

The build failure here is due to examples/Anet/E16/BTT SKR 1.3 build now becoming too large. It will be good to attend to the size of the base build and work on size optimizations for the benefit of Melzi. While I try to be diligent about keeping the base build size from increasing, it can be hard to avoid among a flood of contributions.

The build failure here is due to examples/Anet/E16/BTT SKR 1.3 build now becoming too large.

I think we see different things? I see the following that failed: https://github.com/MarlinFirmware/Configurations/actions/runs/7586725567/job/20665533485?pr=1006

Building Configurations in config/examples/AnyCubic/Mega Zero 2.0/Anycubic V1 ...
Building environment melzi_optiboot_optimized for board MELZI_CREALITY (1505)...

Error: The program size (130372 bytes) is greater than maximum allowed (130048 bytes)
*** [checkprogsize] Explicit exit, status 1
========================= [FAILED] Took 27.77 seconds =========================

Environment               Status    Duration
------------------------  --------  ------------
melzi_optiboot_optimized  FAILED    00:00:27.768
==================== 1 failed, 0 succeeded in 00:00:27.768 ====================